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FOREWORD 


This  report  describes  a method  for  automating  many  of  the  tasks  involved 
in  the  complex  process  of  maintaining  a large  ccmiputer's  operating  system. 

The  method  was  designed  and  implemented  for  use  with  the  SCOPE  3.4  operating 
system  released  by  the  Control  Data  Corporation  for  their  6000  series  of 
computers. 

This  automated  maintenance  tool  was  developed  in  the  Programming  Systems 
Branch  (K74)  of  the  Computer  Programming  Division.  This  report  was  reviewed 
by  Mr.  Hermon  Thombs,  Head  of  the  Programming  Systems  Branch. 
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INTRODUCTION 


I 1 

The  Naval  Surface  Weapons  Center  (NSWC) , Dahlgren  Laboratory,  operates  ' 

two  large  general-purpose  computers  built  by  the  Control  Data  Corporation:  a | 

CYBER  70  model  74  system,  and  a 6700  multiprocessor  system.  Each  of  these 
two  computers  operates  under  the  control  of  the  SCOPE  3,4  operating  system. 

SCOPE  is  a group  of  programs  and  subprograms  that  controls  the  input,  ccmpila-  ^ 

tion,  loading,  execution,  and  output  of  all  programs  submitted  to  the  computers, 

A knowledge  of  SCOPE  3.4,  and  of  SCOPE  systems  programming  methods,  will  be 
helpful  in  understanding  the  material  presented  in  this  report. 

Although  the  SCOPE  3.4  operating  system  is  a Control  Data  product,  its  i 

implementation  at  NSWC  contains  numerous  locally  installed  modifications, 
known  generically  as  "local  mods."  A local  mod  is  introduced  into  a program 
to  correct  known  errors  in  the  program,  to  enhance  its  performance,  or  to 
eliminate  inefficiencies. 

Generation  of  a local  mod  is  an  exacting  task,  requiring  significant  ^ 

amounts  of  expensive  resources  such  as  dedicated  computer  time  and  systems 
programmer  manpower.  This  report  describes  a method  for  automating  many  of 
the  tasks  involved  in  creating  and  maintaining  local  mods,  which  results  in 

increased  productivity.  Itiis  automation  tool  is  also  applicable  to  other  • 

Control  Data  operating  systems  (NOS  and  NOS/BE)  and  to  programming  tasks  other  i 

than  operating  systems  maintenance.  | 

I 

No  automated  method  can  substitute  for  the  creativity  of  an  experienced 
programmer;  many  necessary  programming  tasks,  however,  are  essentially  j 

noncreative  and  repetitive  in  nature.  An  example  of  such  a task  is  the 

installation  of  a local  mod  after  the  rood  has  been  designed.  The  installation  ! 

process  (Figure  1)  involves  coding  and  executing  an  "installation  deck" 

(described  in  the  next  section).  Errors  in  an  installation  deck  can  cause 
substantial  amounts  of  systems  programmer  manpower  and  computer  time  to  be 
wasted;  in  extreme  cases,  incorrect  implementation  of  a mod  can  result. 

I 

Fortunately,  the  installation  process,  including  the  coding  of  the 
installation  deck,  can  be  automated  extensively.  This  is  accomplished  by  ! 

using  BEG IN/ REVERT, * a high-level  command  language  facility.  BBGIN/REVERT 
allows  conditional  execution  of  control  statements  and  provides  for  storing 

"subroutines"  of  control  statements  on  files  known  as  "procedure  files."  j 

‘ 

The  automated  installation  process,  called  the  "COMPILE  procedure,"  is 
actually  a mixture  of  BEGIN/REVERT  procedures  and  FORTRAN  programs.  FORTRAN  j 

is  used  because  BEGIN/REVERT  is  limited  in  its  ability  to  express  complicated 

logical  expressions.  Procedure  files  and  data  files  are  created  by  FORTRAN  ‘ 

programs  and  executed  via  the  BEGIN/REVERT  facility.  ^ 


* Under  NOS  and  NOS/BE,  CYBER  Conmand  Language  (CCL)  is  used.  BBGIN/REVERT 
was  developed  by  the  University  of  Washington,  Seattle,  Washington. 
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LOCAL  MOD 
INSTALLATION 
PROCESS 


Figure  1.  Data  Flow  in  Installing  a Local  Mod 


USING  THE  SOFTWARE  MAINTENANCE  PACKAGE— INSTALLING  LOCAL  MODIFICATIONS 


The  SCOPE  3.4  operating  system  consists  of  several  hundred  distinct 
program  modules.  Each  program  module  has  unique  characteristics  that  may 
affect  the  implementation  of  changes  to  the  program.  Differences  between 
programs  include  the  following  types: 

Structural  differences.  Programs  can  be  peripheral  processor  progr2uns 
or  central  processor  programs.  They  can  be  divided  into  multiple  overlays. 

Location  differences.  Programs  can  be  on  one  of  the  program  libraries 
provided  by  Control  Data,  or  on  a locally  originated  source  library. 

Translation  differences.  Progrcuns  may  be  coded  in  assembly  language 
or  FORTRAN  (even  SYMPL,  COBOL,  or  PASCAL).  One  or  more  system  text  overlays 
may  be  required  for  assembly. 

Binding  Differences.  Programs  may  be  relocatable  or  eibsolute;  link- 
editing with  other  modules  may  be  required. 

The  characteristics  of  a program  are  usually  constant  over  the  lifetime  of 
the  program.  The  installation  of  a program,  as  expressed  in  the  contents  of 
the  installation  deck,  is,  of  course,  highly  dependent  on  these  characteristics. 
For  example,  note  the  differences  (and  similarities)  in  the  installation  decks 
of  PFA  (Figure  2)  and  RBTC  (Figure  3) . 
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PAUSE.  MOUNT  EJITLS,  PLSPAK. 

MOUNTl, EDITLB  . 

AITACH,LOCALPL,SNiEO ITLt. 

J‘>OAT£,P=LOCALPL,  C*L  CC Al » U, *»/ . 

MOUNT!, PL SPAK. 

AT  T ACM  , PL  IB  , S N=  PL  SP  A K . 

UPDATE  ,P=FLlt,,  I=LOCAL,  0,  X. 
REOUEST,BFFA,»PE,SN*ECITLe. 

Compass, I, s= IP  TEXT,  s=fptext, s=schtext, b^mpfa. 
CATALOG, SPFA,  . . . 
itemize, 6FFA,E,N. 


Z-o-P 
' AOOFILE 
/DECK  LOCAL 
/CALL  SCABCOM 
/CALL  PFA 

<TH£  TEXT  OF  THE  LCCAL  MOD  COES  HERE* 

• • • 


Figure  2.  Part  of  the  Installation  Deck  for  PFA 


PAUSE.  MOUNT  EDITLB. 

MOUNTT,EOITLB. 

ATTACH, LOCALFL, SNsEOIToB. 
update, F»cOCALPLt  C«L OC AL ,Q,*«/ . 
attach, PL 1Z,SN=E0ITLB. 

UPDATE, P=FL1Z, I*L0:AL,Q. 
REQUEST,BRBTC,*PF,SN«EDITL6. 
FTn,  I,R,PL=9999999,S=CPCTtXT. 
ATTACH, SVSLIB. 

ATTACH, KPSLIB . 
LIBRAFY,SYSLI6,KPSLIB. 
LOSET.PRE SET=ZE«0. 

LOAD,  LGO. 

NOGO, BRPTC. 
catalog,bi;btc,  . . . 
itemize, Bi;eTC,E,N. 


7-8-9 
/AOOFILE 
/DECK  LOCAL 
/CAlL  PLtZCOM 

/call  RETC 

<THE  TEXT  OF  THE  LOCAL  MOO  GOES  HERE> 


Figure  3.  Part  of  the  Installation  Deck  for  RBTC 
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Before  the  COMPILE  procedure  was  implemented,  the  systems  programmer 
had  to  either  (a)  punch  such  an  installation  deck  for  each  local  mod,  which 
was  discarded  after  the  mod  was  processed,  or  (b)  save  a deck  for  each  pro- 
gram, using  it  every  time  the  program  was  modified.  Of  course,  option  (a) 
duplicated  a lot  of  effort,  but  (b)  was  just  as  bad  since  it  led  to  filing 
problems  and  errors  when  deck  format  changes  were  necessary. 

Using  the  COMPILE  procedure,  the  above  two  example  decks  are  replaced  by 

(1)  BEGIN, COMPILE, ,PFA. 

(2)  BEGIN, COMPILE, ,RBTC. 

The  COMPILE  procedure  then  generates  streams  of  control  statements  equivalent 
to  those  in  Figures  2 and  3.  Notice  that  the  systems  programmer  is  relieved 
of  the  responsibility  of  specifying  any  of  the  characteristics  of  the  program 
being  modified.  He  is  also  relieved  of  the  need  to  do  a lot  of  keypunching! 

Replacing  control  statements  with  BEGIN/REVERT  procedures,  however,  is  not 
an  exciting  breakthrough.  The  significant  feature  of  the  COMPILE  procedure  is 
its  ability  to  configure  itself  to  process  programs  that  have  highly  divergent 
characteristics. 

How  does  the  COMPILE  procedure  know  the  characteristics  of  all  the  programs 
in  the  operating  system?  The  procedure  contains  a data  base  that  describes 
every  significant  characteristic  of  every  program  in  SCOPE.  The  data  base 
is  easily  maintained  because  it  is  a card  image  file.  Each  card  contains 
the  characteristics  for  one  program  in  a shorthand  notation.  For  example, 
the  cards  for  the  PFA  and  RBTC  programs  are 

PFA  BP  05  PA 

RBTC  ZF  TB  LSK 

which  are  read 

"PFA  is  located  on  PLIB  (B) . It  is  a peripheral  processor 
program  (P) . It  has  multiple  overlays,  the  last  of  which 
is  SPA  (05PA)." 

"RBTC  is  located  on  PLIZ  (Z) . It  is  a FORTRAN  program  (F) . 

It  needs  system  text  CPCTEXT  for  compliation  (TB) , and  user 
libraries  SYSLIB  and  KPSLIB  for  loading  (LSK)." 

Part  of  the  data  base  is  a glossary  that  explains  the  notations  used  in  the 
data  base.  The  user  of  the  COMPILE  procedure  can  override  any  information  in 
the  data  base  by  specifying  optional  parameters  on  the  BEGIN  command  (see 
Appendix  A,  NSWC  User's  Guide  for  the  Software  Maintenance  Package). 

A FORTRAN  program  (also  named  COMPILE)  within  the  COMPILE  procedure  creates 
the  control  card  images  which  are  ultimately  executed  to  perform  the  installa- 
tion. The  COMPILE  program  finds  out  what  SCOPE  program  is  being  installed  (frctn 
the  first  parameter  on  the  BEGIN  command)  and  searches  the  data  base  for  the 
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program's  entry.  Any  optional  parameters  on  the  BEGIN  command  are  used  to  over- 
ride configuration  values  from  the  data  base  entry  (using  the  rules  explained 
in  the  user's  guide),  and  the  resulting  values  are  used  to  build  a new, 
temporary  procedure  file  named  CTLCDS,  which  is  subsequently  executed  via 
a nested  BEGIN  call. 

The  COMPILE  program,  which  builds  the  card  images,  contains  by  necessity 
logical  equations  of  some  complexity.  Figure  4,  for  example,  shows  the  flow 
of  a minor  part  of  the  COMPILE  program — the  decision  whether  or  not  to  generate 
a MOUNT  command  to  mount  the  EDITLB  device  set.  Maintainability  of  the  COMPILE 
program  is  pocsible  in  spite  of  its  complexity  because  the  program  is  modular 
and  we 11- documented  with  in-line  comments. 


EXPERIENCE  WITH  THE  MAINTENANCE  PACKAGE 


As  Of  November  1978,  the  maintenance  package  has  been  in  production  use 
for  eight  months.  An  informal  class  was  given  to  all  users  (the  K74  and  CDC 
Systems  Programming  Group)  when  the  package  was  introduced,  A user's  guide 
(Appendix  A)  was  written  and  is  revised  periodically  to  reflect  changes  in  the 
package  or  to  meet  user  requests  for  more  information. 

The  package  itself  has  been  modified  several  times  to  add  or  change 
features,  following  user's  suggestions.  The  package  has  been  enthusiastically 
accepted  by  the  users,  and  it  appears  to  be  contributing  to  a more  productive 
and  stable  environment  of  system  iiodif ications . 

Although  the  COMPILE  procedure  has  been  highlighted  in  this  report,  the 
maintenance  package  includes  other  procedures  used  by  the  Systems  Programming 
Group.  They  are  described  in  the  user's  guide  (Appendix  A). 

Appendix  B discusses  the  SCOPE  system  utility  programs  used  in  installing 
local  mods. 
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Figure  4.  Logic  Flow  for  the  Decision  to  Mount  the  EDITLB  Device  Set 
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APPENDIX  A 


NSWC  USER'S  GUIDE 

FOR  THE  SOFTWARE  MAINTENANCE  PACKAGE 


APPENDIX  A 


NSWC  USER'S  GUIDE  FOR  THE  SOFTWARE  MAINTENANCE  PACKAGE 


This  appendix  is  an  example  of  the  NSWC  user's  guide  for  the  COMPILE 
procedure  and  other  procedures  in  the  maintenance  package.  This  example  has 
been  edited  to  delete  proprietary  and  sensitive  information  (i.e.,  passwords). 

The  user's  guide  is  meant  to  be  an  informal  document,  which  can  be  easily 
changed  when  features  are  added  or  when  responses  from  the  users  indicate  that 
a feature  should  be  explained  more  clearly. 

A knowledge  of  SCOPE  3.4  operating  system  installation  methods  and  of 
NSWC's  local  modification  process  is  necessary  to  fully  understand  the  material 
in  the  user's  guide. 

COMPILE  PROCEDURE 

The  COMPILE  procedure  generates  the  control  cards,  UPDATE  directives,  and 
EDITLIB  directives  necessary  for  modifying  components  of  the  SCOPE  3.4  operat- 
ing system  at  NSWC/DL. 

The  Basic  Calls 

BEGIN, COMPILE, , prog, OPT=A.  (To  get  a listing  only) 

BEGIN, COMPILE, , prog, cy. 

BEGIN, COMPILE, ,prog,cy,ac. 

where 

prog  — the  name  of  the  program  to  be  compiled.  This  is  a required  para- 
meter. 

cy  — the  cycle  number  for  cataloging  the  binary  result.  This  number 
is  required  when  OPT=C  is  in  effect  (default  OPT  is  OPT=AC) . 
ac  — programmer  name  to  be  used  for  the  binary  file's  account  code. 

This  code  is  required  when  OPT=C  is  in  effect,  except  for  Systems 
Programming  Group  members,  for  whom  it  is  optional  (it  is  computed 
from  the  job  card  if  not  specified). 

General  Information 

COMPILE  gets  the  information  needed  to  UPDATE,  assemble,  load,  and  EDITLIB 
i the  requested  program  frcxn  its  data  base,  on  the  local  file  CDATA.  Every  pro- 

I ■ gram  on  PLIA,  PLIB,  PL12,  PLIZ,  and  PLIT  is  represented  on  this  data  base.  Any 

I data  base  information  can  be  overridden  by  specifying  one  or  more  of  the 

: optional  parameters  described  below.  If  you  have  a local  file  CDATA,  COMPILE 

' • will  use  your  file  as  its  data  base.  Similarly,  if  you  have  local  files  named 

1 A-1 


LOCALPL,  PLIA,  PLIB,  PL12,  PLIZ,  or  PLIT,  COMPILE  will  UPDATE  from  your  file 
instead  of  from  the  standard  program  library  of  the  same  name. 

In  addition,  COMPILE  will  do  all  mounting  and  dismounting  of  the  correct 
Device  Sets.  It  will  not  mount  a set  until  it  is  necessary,  and  will  dismount 
a set  as  soon  as  it  is  no  longer  needed. 

If  Sense  Switch  1 is  on,  COMPILE  will  not  pause  to  ask  the  operator  to 
mount  the  packs  (this  option  is  useful  during  System  Time).  If  Sense  Switch 
2 is  on,  output  from  UPDATE  will  be  printed  in  all  cases  (output  is  normally 
suppressed  if  UPDATE  completes  successfully) . 


The  Optional  Parameters 


OPT  = X 


PL  = X 

TXT  = X 


where  x can  be  one  of  the  following: 

A — assemble  the  program 

AC  — assemble  and  catalog  the  binary  (default) 

AE  — assemble  and  EDITLIB  the  program 

ACE  — assemble,  catalog,  and  EDITLIB 

the  program  library  on  which  "prog"  resides;  x 
must  be  PLIA,  PLIB,  PLIZ,  PLIT,  or  PL12. 

specifies  System  Texts  necessary  for  assembly. 
Texts  specified  by  this  parameter  are  exclusive 
or'ed  with  the  data  base  value,  which  is  then 
exclusive  or'ed  with  the  default.  This  final 
value  is  used  in  assenbly.  The  defaults  are 
as  follows: 


PLIA  PP  programs: 
PLIA  CP  programs: 
PLIB  programs: 
PL12  programs: 
PLIZ  PP  programs: 
PLIZ  CP  programs: 


TXT  = E 
TXT  = G 
TXT  = BCDEF 
TXT  = DEFH 
TXT  = E 
TXT  = M 


The  Texts  are  as  follows: 


A - CMRTEXT 


H - STATEXT 


B - CPCTEXT 
C - CPUTEXT 
D - IPTEXT 
E - PPTEXT 
F - SCHTEXT 
G - SCPTEXT 


I - 0 (use  no  Texts) 
J - lOTEXT 
K - LDRTEXT 
L - PFMTEXT 
M - SYSTEXT 


A-2 


I 


LIB  = X 


When  I is  in  effect,  it  overrides  all  others; 
i.e,,  TXT=ABIKL  is  treated  as  TXT=I. 

If  the  job  has  a local  file  named  BTEXTS,  then 
COMPILE  will  get  the  required  texts  from  this 
file . 


libraries  necessary  for  loading  relocatable  CP 
programs.  These  are  exclusive  or'ed  with  the 
data  base  values  like  the  Texts  are.  The  libraries 
are  as  follows: 


S - SYSLIB 
K - KPSLIB 
U - USERLIB 
D - DMS170 
O - SYSOVL 
F - FORTRAN 


C - COBOL 
R - RUN2P3 
I - SYSIO 
M - SYSMISC 
G - IGS274 


DECK  = X — 


REL  = R “ 


SP  = X — 


VER  = X — 


PS  = X — 


The  user  must  attach  KPSLIB  when  it  is  needed; 

COMPILE  will  attach  other  requested  user  libraries, 
unless  a local  file  of  the  same  name  already  exists. 

used  when  the  LOCALPL  deck  name  (or  the  SCOPE 
PL  deck  name)  is  different  from  the  program  name. 

An  example  is  1Z2,  which  has  a deck  name  of  "IMl." 
This  parameter  usually  only  appears  in  the  data 
base . 

CP  COMPASS  programs  are  assumed  to  t>e  absolute  unless 
REL=R  is  specified,  which  causes  a LOAD/NOGO  to 
be  performed.  Don't  use  REL=R  if  the  program  must 
remain  relocatable  (e.g.,  QUEDUMP,  SYSEQ,  CPC). 

an  indicator  that  "prog"  needs  special  pro- 
cessing in  COMPILE  because  of  nonstandard  char- 
acteristics in  its  method  of  installation. 

This  parameter  usually  only  appears  in  the 
data  base.  An  example  of  such  a special  pro- 
gram is  1Z2,  which  needs  a "*DEFINE  CT71"  card 
in  its  UPDATE  directives.  To  disable  any  SP 
value  in  the  data  base,  SP=NONE  can  be  specified 
on  the  BEGIN  card  for  COMPILE. 

program  version  indicator.  See  the  section 
below  on  "Special  Programs"  for  use  of  this 
parameter . 

option  for  presetting  core  for  CP  programs  that 
undergo  a LOAD/NOGO.  Default  is  PS=ZERO.  If 
PS=NONE  is  specified,  no  presetting  is  done. 
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If  the  parameter  begins  with  an  asterisk  (*) , 

a PRESETA  is  performed  instead  of  a PRESET.  i 

See  the  Loader  Manual  for  details.  Examples: 

PS  = lOOB  PS  = *INDEF 

OVl  = X — name  of  the  first  overlay  in  "prog."  Default 
is  the  value  of  "prog." 

0V2  = X — name  of  the  last  overlay  in  "prog."  Default  is 
the  value  of  "OVl." 

FL  = n — field  length  for  EDITLIBing  CP  programs.  If  not 
specified,  the  current  value  will  be  unchanged. 


The  UPDATE  Process 

COMPILE  does  two  UPDATES.  The  first  is  against  the  LOCALPL  with  the 
file  UPDIN  as  input,  and  LOCAL  as  the  compile  file.  The  second  is  against 
the  SCOPE  PL,  with  LOCAL  as  input. 

COMPILE  builds  the  file  UPDIN.  Its  structure  is  as  follows; 


/ ACCFiLt 
/DECK  itOMOECKS 
/CULL COM 

<EMiK£  CONTENTS  OF  FILE  •OECKS»> 

/ACCFILE 
/DECK  Si<DECK> 

/IF  DECK, <OECK>, 1 
/CALL  <OECK> 

/IF  -QECK,<0ECK>,1 
♦COFPILE  <CECK> 

<LNTlt<c  CONTENTb  OF  FILE  •IOENTS*> 

<CCNTEN7S  OF  NEAT  RECORD  CF  INPUT  F1LF> 

F 

where  "<DECK>"  is  the  value  of  the  DECK  parameter  (which  defaults  to  "prog") . I 

The  user  can  use  the  files  DECKS  and  IDEMTS  to  introduce  UPDATE  directives.  * 

If  this  is  done,  and  if  the  HEADER  procedure  is  called,  care  must  be  taken  • 

to  never  rewind  these  files,  since  HEADER  also  puts  directives  on  these  files.  - > 

If  no  cards  are  to  be  read  frcm  the  INPUT  file,  an  empty  record  must  be  included 
(or,  under  INTERCOM,  the  file  should  be  disconnected).  The  UPDATE  listings  ' 

are  normally  not  printed  unless  an  UPDATE  error  occurs. 
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Verify  Mode 

In  Verify  Mode,  the  control  cards  created  by  COMPILE  (on  the  file  CTLCDS) 
are  listed,  not  executed.  The  UPDATE  directives  and  EOITLIB  directives  on  the 
file  UPDIN  are  also  listed.  Verify  Mode  is  automatically  entered  when  COMPILE 
is  executed  from  INTERCOM;  it  is  entered  from  batch  whenever  a local  file  neuned 
VERIFY  exists  (all  the  user  needs  to  do  is  a "REWIND,  VERIFY."  before  calling 
COMPILE) . 


Assembling  Multiple  Routines 

If  eXMPILE  is  called  with  DECX=*  specified,  then  the  four  UPDATE  directives 
flagged  with  asterisks  above  (under  "The  UPDATE  Process")  are  not  included. 

If  the  first  character  in  "prog"  is  an  asterisk  (for  example,  PROG=*PFDBCKS) , 
then  COMPILE  does  two  things  — it  removes  the  asterisk  from  the  PROG  value 
and  sets  DBCK=*.  This  option  is  used  when  it  is  desired  to  modify  and  catalog 
multiple  binarys  on  the  same  file.  The  PL  parameter  must  be  specified  to  name 
the  SCOPE  PL  on  which  the  programs  reside.  Example: 


NWcitP5,T0.  ASSEMdLE  PFM  PF  PROGS 
99KK33,F  k. 

ATTACH.FHGFIL  «I0=NV6. 

BEGIN tCCMFlLE  .♦♦PFH, 123,PL=PL18. 

7-8-9 

/CALL  PFA 
/CALL  PFC 
♦COMPILE  PFS 

• 


Multiple  COMPILE  Executions 

Multiple  "BEGIN, COMPILE"  executions  may  be  stacked  within  one  job.  It  ^ 

; is  possible,  for  instance,  to  assemble  the  System  Texts  in  one  COMPILE  step,  > 

and  use  them  in  assembling  another  program  in  a following  step. 


(It- is  necessary  to  Include  /CALLS  or 
*COMPlLEs  for  each  deck  to  be  Included; 
the  value  of  PROG  is  used  only  as  a name 
for  the  binary  file,  and  OECK°*  is  simulated. 


► 
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Special  Programs 

CMRS  — If  PRCX3=CMRS  is  specified,  all  four  CMRs  are  assembled 
(all  on  the  file  BCMRS) . CMRl  and  CMR3  are  not  listed. 

The  CMR  date  must  be  specified  as  VER=mmddyy. 

CMRn  — If  PROG=CMRn  (n=0,l,2,3),  the  corresponding  CMR  is  assembled, 
listed,  and  put  on  the  file  BCMRn.  If  the  CMR  date  is 
not  specified,  an  assembly  warning  will  occur,  and  the 
current  date  will  be  used. 

CMR  — If  PROG=CMR,  the  default  CMR  (currently  CMRO)  is  assembled 
on  the  file  BCMR.  An  assembly  warning  will  occur,  noting 
that  the  default  CMR  was  used. 

TEXTS  — If  PROG=TEXTS  is  specified,  the  System  Texts  CPCTEXT 
through  STATEXT  are  assembled  on  the  file  BTEXTS. 

OSY  — If  PROG=OSY  is  specified,  the  844  Buffer  Controlware  is 
processed.  The  binary  cards  must  be  the  input  record, 
and  the  version  must  be  specified  via  the  VER  parameter 
(e.g. , VER=A10) . 


The  /LOCAL  Pseudo-UPDATE  Directive 


The  UPDATE  directives  necessary  for  implemen'ting  a local  modification 
resemble  the  following  example: 


/luEM  LS99P«iOGfi 
/BEFCnE  CECKR.3 
/IF  -UEF, INSTALL 
♦IDEM  LS99PK0GK 
•INiEPT  F0RPK0&H.6 

♦ L999PfiCGR  ...  <NAME>  ...  <LiAT£> 

« 

• <COHHLNTS> 


• • • 

<ThE  (JIRECTIWES  FOR  THE  MOOIFICATIUI'.> 

• • . 

♦ccmfile  prug 

•/  ENo  OF  HOD  L999PfO&R 
/ENGIF 

//  ENO  CF  HOO  L999PROGP 


A 

a 

C 

0 

E 


F 

G 

H 

I 
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The  /LOCAL  card  causes  the  COMPILE  procedure  to  provide  the  cards  labeled. 
A through  I,  requiring  the  user  to  provide  only  the  comments  and  directives 
for  the  modification.  The  format  of  the  /LOCAL  card  can  be  any  of  the  following; 

/LOCflL  L9S'3 

/LOCAL  L999f»iCGR 

/local  L999FRC&K,H0fiPRU&H 

/LOCAL  L999FfiC&k,0ECKR 

/local  L999FRLOF,H0RFf<0&H,  CECKR 

The  local  mod  number  (as  L999)  must  be  provided.  The  letter  can  be  D,  G, 

I,  L,  P,  or  Y.  If  the  rest  of  the  mod  name  (progr)  is  omitted,  the  value  of 
the  "prog"  parameter  (truncated  to  five  characters)  is  used. 

If  the  header  mod  name  is  omitted,  the  name  is  assumed  to  be  HDR  followed 
by  the  value  of  the  "prog"  parameter  (truncated  to  six  characters). 

If  the  COMDECK  name  (deckr)  is  omitted,  the  value  of  the  "deck"  parameter 
is  used. 

If  the  user  provides  the  ‘COMPILE  card,  the  procedure  won't;  if  the  pro- 
cedure provides  the  card,  it  will  use  the  value  of  the  "prog"  parameter.  The 
‘COMPILE  card  must  be  the  last  card  in  the  modification  if  the  user  provides 
it. 


The  first  card  after  the  /LOCAL  card  must  be  a comment  card.  COMPILE 
will  insert  the  local  mod  name  into  columns  3-11  of  this  card.  Columns  12-20 
will  be  cleared.  If  columns  21-30  are  empty,  the  value  of  the  AC  parameter 
will  be  inserted,  and  if  columns  51-60  are  empty,  the  current  date  will  be  in- 
serted. 

If  the  /LOCAL  directive  is  used,  all  cards  in  the  local  mod  will  be 
punched.  Multiple  local  mods,  each  prefaced  by  /LOCAL,  can  be  present.  When- 
ever /LOCAL  is  used,  the  listing  from  the  I/XALPL  UPDATE  will  be  printed. 

HEADER  PROCEDURE 

The  HEADER  procedure  produces  the  UPDATE  directives  necessary  when  adding 
the  first  local  modification  to  a program.  A COMDECK  and  a "header  mod"  are 
produced. 

A new  COMDECK  for  the  LOCALPL  is  created.  This  COMDECK  will  be  used  to 
contain  all  local  modification  code  for  the  program,  including  code  added  in 
the  future.  The  format  of  the  COMDECK  is 

/CCkOECK  <C0Mb<> 

•/  EcGlN  MOOb  Tc  <PR0G> 

*/  END  OF  NODS  TO  <PR0&> 
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The  variable  pareuneters  "comdk"  and  "prog"  are  explained  below.  The 
COMDECK  is  never  produced  when  we  are  introducing  a modification  to  a SCOPE 
coimnon  deck;  all  local  code  for  SCOPE  common  decks  goes  into  one  of  the  LOCALPL 
COMDECKS  named  SC4AC0M,  SC4BC0M,  IN4C0M,  or  PLIZCOM,  which  already  exist. 

The  "header  mod"  is  a set  of  comment  cards  that  is  added  near  the  be- 
ginning of  every  locally-modified  program.  It  serves  as  a notice  that  the  pro- 
gram is  in  fact  locally  modified.  Every  subsequent  local  modification  will  add 
its  own  set  of  comments  after  the  header  mod,  so  that  a concise  summary  exists 
of  all  the  local  changes  to  the  program.  The  format  of  the  header  mod  cards 
is  shown  below: 

/ICENT  H0k<TPR0o> 

/oEFUkE  <C0MUK>,3 
♦iLENT  hUR<TP.'»bb> 

♦INEtkT  <iDtN  T>,  <SEQr40> 


--LOCAL  MOUIF IC AT1CNS-- 


♦ 


♦CCkPiLf  <PRu&> 

*/  ENO  uP  MOD  HuH<TPRO&> 

//  ENO  OF  MCD  M0P<TPR0&> 

The  variable  parameter  "tprog"  is  "prog"  truncated  to  six  characters. 

The  HEADER  procedure  puts  the  COMDECK  on  the  file  DECKS,  and  the  header 
mod  is  put  on  the  file  IDENTS.  The  COMPILE  procedure  processes  these  files, 
merging  their  contents  into  the  set  of-  UPDATE  directives  it  builds.  Two 
separate  files  are  used  in  order  to  keep  everything  in  sequence  in  case  HEADER 
is  called  more  than  once;  the  files  are  not  rewound,  so  that  their  contents 
are  cumulative. 

The  COMDECK  and  the  header  mod  are  also  written  to  the  PUNCH  file  for 
subsequent  punching.  This  can  be  disabled  by  including  a "ROUTE, PUNCH, DC =SC. " 
card  as  a final  control  card. 

HEADER  is  executed  as  follows: 

BEGIN, HEADER, ,prog , comdk , ident, seqno. 

The  "prog"  parameter  is  required;  the  others  are  optional.  Each  of  the  para- 
meters are  listed  below: 

prog  — the  name  of  the  program  being  modified.  In  cases  where 
the  binary  deck  name  is  different  from  the  UPDATE  PL 
deck  name,  the  latter  should  be  used. 


comdk  — the  name  for  the  C0MDBC3C.  If  omitted,  "prog"  is  used  as  the 

COMDECK  name.  If  the  program  being  modified  is  a SCOPE  common 
deck,  one  of  the  following  must  be  specified  as  "comdk:" 
SC4AC0M,  SC4BC0M,  IN4C0M,  or  PLIZCOM. 

ident,  — these  parameters  describe  the  location  in  the  program  where 

seqno  the  header  mod  is  to  be  inserted.  If  "ident"  is  omitted, the 
value  of  "prog"  is  used;  if  "seqno"  is  omitted,  "6"  is  used. 

The  user  must  usually  examine  a listing  of  the  program  to 

be  modified,  in  order  to  intelligently  specify  values  for  these 

parameters. 

Examples 

BEGIN, HEADER, , lAJ . 

A header  mod  is  inserted  at  1AJ.6  and  LOCALPL  COMDECK  "lAJ"  is 
created. 

BEGIN , HEADER, , lAJ , IDENT=SC41926 , SEQNO=134 . 

A header  mod  is  inserted  at  SC41926.134,  which  must  be  a card  within 
lAJ.  The  LOCALPL  COMDECK  "lAJ"  is  created. 

BEGIN, HEADER, , INIT,SC4BC0M. 

A header  mod  is  inserted  at  INIT.6.  Since  INIT  is  a SCOPE  common 
deck  on  PLIB,  SC4BC0M  must  be  specified  as  the  COMDECK  name.  No 
new  LOCALPL  COMDECK  is  created. 


DSBUILD  PROCEDURE 

The  DSBUILD  procedure  builds  a deadstart  tape  from  the  running  system. 
If  any  permanent  files  containing  transfer  records  are  attached,  the  transfer 
records  on  those  files  will  be  used;  otherwise,  the  transfer  records  will  be 
taken  from  the  running  system.  If  necessary,  additional  EDITLIB  directives 
are  taken  from  input  cards. 

DSBUILD  is  executed  as  follows : 

BEGIN, DSBUILD, , tape, option. 

Both  parameters  are  required.  They  are: 

tape  — for  production  of  deadstart  tapes,  the  number  of  the  tape 

(102,  etc.);  for  test  tapes,  any  1-5  character  name.  The  Ifn 
and  VSN  of  the  created  deadstart  tape  will  be  "A"  followed  by 
this  parameter. 
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option  — must  be  SYSTEM  to  create  a production  tape,  or  TEST  to  create 

a test  deadstart  tape.  When  SYSTEM  is  specified,  the  OSCOMPARE 
procedure  is  automatically  called  and  the  ITEMIZE  of  the  tape 
is  cataloged  on  the  EDITLB  pack.  Never  use  SYSTEM  when  build- 
ing a test  tape. 

When  invoked,  the  DSBUILD  procedure  pauses,  waiting  for  an  entry  of  n.YES; 
when  this  is  entered,  an  EDITLIB, RESET  is  performed  and  then  the  operator  is 
asked  to  run  the  daily  EDITLIBs  in  order  to  ensure  that  the  running  system 
contains  the  correct  E33ITLIBs.  The  EIDITLIB  job  should  be  killed  or  dropped 
when  it  displays  "TURN  SEC, EDITLIB, OFF." 

By  entering  n.NO,  the  EDITLIB, RESET  and  EDITLIB  insertions  can  be  bypassed. 
This  should  not  be  done  when  building  a production  tape. 

When  building  a test  tape,  you  can  do  a compare  against  the  current 
production  tape  by  executing 

BEGIN,DSCOMPARE, , tape . 

The  EDITLB  pack  is  mounted  by  DSCOMPARE.  DSCOMPARE  is  automatically  called 
when  building  a production  tape. 

As  an  example,  suppose  it  was  necessary  to  build  production  Deadstart 
Tape  106,  with  changes  to  MIK,  IRCP,  and  the  CMRs.  Something  unusual  is  also 
being  introduced:  a new  PP  routine  ALZ  and  a new  CP  routine  SNXLP  are  being 
added.  They  cannot  be  EDITLIBed  in  because  they  will  not  run  without  a CMR 
change.  They  are  both  on  the  file  BSNXLPALZ.  The  deck  to  build  this  tape 
would  look  sonething  like  this: 

NXXYY,MTltTO. 

•J'JZZ'jSt  fnu. 

j£&IN|f'0bM  tWS  N=  t ul  TLd  • 

ATTACnibMTSf  ••• 

ATTACH, BI:?CP  , ... 

A T T AC H , d C M n S , ... 

ATTACH,dSNXlPAl.Z,  ... 

ATTACH.PfiCFiL, I0«NVe. 
jcblN.CScUlLC, ,106,SYSTEM. 
tXlT. 
txi  T. 

kcUUEST ,A10e ,kING,VSN= A106. 

7-8-9 

AQu  (ALZ,cSNXLPA,AL-0) 
lIoRAPY  (NUCLc.US,0L0> 

AJu(SNXLR,cSRXtPA«At=l,PL=30000, FLC«0) 

finish. 

6-7-6-C 

Note  that  a dunny  REQUEST  card  is  necessary  to  satisfy  tape  staging. 


I 
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Both  the  DSBUILD  and  the  DSCOMPARE  procedures  have  a verify  mode,  as 
described  in  the  COMPILE  procedure  user's  guide. 

The  SCOPE  transfer  records  are  listed  below: 
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CEA  - 

CES 

Deadstart  Initialization 

PCI  - 

XXX 

C.E.  Diagnostics 

CED  - 

DTS 

CONTROL 

CMRO  - 

CMR3 

CMRs  i 

COM  - 

P 

CONTROL 

OSY 

844  Buffer  Controlware 

STL 

PP  Resident 

IRCP 

Deadstart  CP  Routine 

MTR 

Monitor 

DSD 

System  Display  (only  the  main  overlay 

is  a transfer  record;  DSBUILD  correctly 
puts  the  remaining  overlays  into 
PPLIB) 
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SYSTEM  UTILITIES  USED  IN  INSTALLING  A rX)CAL  MODIFICATION  ' 


A local  mod  is  written  as  a source  language  correction  set  that,  through 
several  steps,  becomes  implemented  as  a change  to  the  running  operating  system. 
The  SCOPE  utility  programs  used  in  this  process  are  discussed  on  the  following 
pages;  the  utilities  are 

• UPDATE 

• Language  Translators 

• LOADER 

• EDITLIB 


UPDATE  - SOURCE  LIBRARY  MAINTENANCE  UTILITY 

The  UPDATE  program  is  used  to  maintain  files  containing  source  programs. 

These  Program  Library  files,  or  PLs,  are  implemented  in  a random-access  compressed 
card  image  format  which  allows  quick  access  and  efficient  storage  utilization. 

An  UPDATE  PL  contains  three  types  of  information:  DECKS,  COMDECKs,  and  IDENTs. 

A DECK  is  a source  program  module.  Each  DECK  has  a name,  and  each  card 
within  a DECK  has  a unique  number,  which  is  invariant.  A correction  set  may 
delete  cards  from  a DECK,  but  these  cards  remain  on  the  PL  so  that  it  can  I 

always  be  restored  to  a previous  state. 

A COMDECK  is  a group  of  source  statements  which  may  be  repeated  in  several 
program  modules.  UPDATE  allows  these  statements  to  be  entered  once  onto  the 
PL  as  a COMDECK,  which  is  referenced  by  each  DECK  that  requires  the  common 
code.  Each  COMDECK  has  a unique  name,  and  the  cards  are  assigned  numbers. 

IDENTs  are  sets  of  modifications  to  DECKS  or  COMDECKs.  An  IDENT  may 
delete  cards  from  or  add  cards  to  a DECK,  COMDECK,  or  another  IDEUT.  Cards  ^ 

that  are  added  are  identified  by  the  unique  IDENT  name  and  a sequence  number 
within  the  IDENT.  IDENTs  are  also  called  "correction  sets."  ■« 

I, 

An  UPDATE  run  (Figure  B-1)  is  controlled  by  control  card  parameters  on  j 

the  UPDATE  command  and  by  input  directives.  Usually,  only  DECKS  named  on  an 
input  directive  (and  COMDECKs  called  by  these  DECKS)  are  output  to  the  source  * 

language  file  (the  "COMPILE"  file).  The  COMPILE  tile  is  usually  used  as  input 
to  a language  translator. 
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Figure  B-1.  The  UPDATE  Process 


LANGUAGE  TRANSLATORS  - FIN  AND  COMPASS 


F 


The  SCOPE  3.4  operating  system  is  written  in  CDC  Extended  FORTRAN  (FTN) 
and  in  assembly  language  (COMPASS) . The  FTO  compiler  accepts  intermixed 
COMPASS  subprograms.  The  translation  process  (Figure  B-2)  converts  a group 
of  source  subprograms  (from  cards  or  from  an  UPDATE  COMPILE  file)  into  a file 
containing  the  relocatable  binary  object  code  of  the  subprograms.  The  object 
tile  is  processed  further  by  the  LOADER.  Translation  is  controlled  by  control 
card  parameters  on  the  FTN  or  COMPASS  command.  Auxiliary  source  input  to 
COMPASS  programs  from  systems  text  overlays  is  often  required. 


Figure  B-2.  The  Translation  Process 


r 


I 


B-2 


THE  IvOADER  UTILITY 
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The  Icxral  mod  installation  process  uses  the  CYBER  LOADER  to  convert  the 
relocatable  binary  object  programs,  produced  by  the  language  translators,  into 
linkage-edited  absolute  overlays.  External  references  are  resolved  by  including 
subprograms  from  object  librarys  where  necessary.  Multiple-overlay  program 
building  is  controlled  by  input  directives;  the  entire  absolutization  process 
(Figure  B-3)  is  controlled  by  control  card  parameters  on  LIBRARY,  MAP,  LDSET, 
LOAD,  and  NOCX)  commands.  The  absolute  overlay  file  is  used  as  input  to  the 
EOITLIB  program. 


EDITLIB  - OPERATING  SYSTEM  MODIFICATION  UTILITY 


The  System  EDITLIB  program  integrates  changes  into  the  SCOPE  3.4  operating 
system.  Two  modes  of  operation  are  featured  — modification  of  the  running 
system  and  creation  of  a modified  deadstart  tape.  Changes  to  the  running 
system  are  temporary,  lasting  only  until  the  first  subsequent  deadstart. 

Creation  of  a deadstart  tape  containing  a local  modification  makes  the 
mod  a permanent  part  of  the  operating  system,  and  is  one  of  the  final  steps 
in  the  installation  of  a local  mod. 

Execution  of  the  EDITLIB  progrcun  (Figure  B-4)  is  controlled  by  control 
card  parameters  on  the  EDITLIB  command,  by  input  directives,  and  by  console 
interaction  with  the  computer  operator. 


Figure  B-4.  EDITLIBing  the  Program  into  the  System  ' 
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NAVAL  AIR  DEVELOPMENT  CENTER 
Warminster,  PA  18976 
ATTN:  Code  50 

Code  85 

Conmanding  Officer 
FLEET  NUMERICAL  WEATHER  CENTRAL 
Mont’rey,  CA  93955 
ATTN:  Code  006 

Officer  in  Charge 

NAVAL  UNDERWATER  SYSTEMS  CENTER 

New  London,  CT  06320 

ATTN:  Richard  Whittaker  (Code  4421) 

Commander 

NAVAL  OCEAN  SYSTEMS  CENTER 
San  Diego,  CA  92152 
ATTN:  Ken  Medin  (Code  9121) 

Commander 

DAVID  W.  TAYLOR  NAVAL  SHIP  RESEARCH 
AND  DEVELOPMENT  CENTER 
Bethesda,  MD  20084 
ATTN:  Lorraine  Minor  (Code  1892.3) 

Commander 

NAVAL  WEAPONS  CENTER 
China  Lake,  CA  93555 
ATTN:  Code  5132 

Commanding  General 

AIR  FORCE  WEAPONS  LABORATORY  (ADP) 

Kirtland  AFB 

Albuquerque,  NM  87117 

ATTN:  Software  Section 
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DISTRIBUTION  (Continued) 


Commanding  General 

EGLIN  MR  FORCE  BASE,  FL  32542 

ATTN;  Mr.  Eddie  Blackwell  (Code  ADTC/ADDSS) 

University  of  Arizona 
UNIVERSITY  COMPUTER  CENTER 
Tucson,  AZ  85721 
ATTN:  Steve  Jay 

FLUOR  CORPORATION 
3333  Michelson  Drive 
Irvine,  CA  92730 
ATTN:  Mr.  Thomas  N.  Burt 

Mr . Frank  Vince 

CONTROL  DATA  CORPORATION  I 

P.  O.  Box  O-HQSIOD 
Minneapolis,  MN  55440 

Burnie  Meyer 

CONTROL  DATA  CORPORATION 
6003  Executive  Blvd. 

Rockville,  MD  20852 

Thomas  L.  Hank  [ 

CONTROL  DATA  CORPORATION  I 

4201  Lexington  Ave.  N. 

Arden  Hills,  MN  55112  [ 

SYSTEMS  AND  DEVELOPMENT  GROUP  j 

CONTROL  DATA  CORPORATION  ' 

4201  Lexington  Ave.  N. 

Arden  Hills,  MN  55112 

Edward  O.  Minasian  | 

2051  28th  Avenue 

San  Francisco,  CA  94116 

Mr.  Art  Hartley  ^ 

CONTROL  DATA  CORPORATION 

4201  Lexington  Ave.  N.  ' 1^ 

Arden  Hills,  MN  55112  I 

Mr.  John  L.  Wardell  ^ 

CONTROL  DATA  CORPORATION  »• 

4201  Lexington  Ave.  N.  \f 

Arden  Hills,  MN  55112 


DISTRIBUTION  (Continued) 


Mr.  James  Whitlock 
Office  of  Computer  Services 
STATE  UNIVERSITY  OF  NEW  YORK 
AT  BUFFALO 
4250  Ridge  Lea  Road 
Buffalo,  NY  14226 

DEFENSE  DOCUMENTATION  CENTER 
Cameron  Station 

Alexandria,  VA  22314  (12) 

LIBRARY  OF  CONGRESS 
Washington,  DC  20540 

ATTN:  Gift  and  Exchange  Division  (4) 


Local : 
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K74  (Zirkle) 
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(2) 

X2101  (GIDEP) 

(2) 

